Rik,

I completely agree that others should weigh in on this.  Those that hummed, please respond.  I see two options that have been presented, where I’ll remove the command-response extension option to simplify things.  I include some notes embedded in your message below.

1. Use protocol extension with object extension

Command looks like:

<epp><extension>
   <r:relay xmlns:r="urn:ietf:params:xml:ns:relay-1.0">
   <k:keyData  xmlns:k="urn:ietf:params:xml:ns:keyrelay-1.0">
     ...
     {key data}
    ...
   </k:keyData>
   </r:relay>
</extension></epp>

Poll message looks looks like:

...
<resData>
   <r:relay xmlns:r="urn:ietf:params:xml:ns:relay-1.0">
   <k:keyData  xmlns:k="urn:ietf:params:xml:ns:keyrelay-1.0">
     ...
     {key data}
     ...
   </k:keyData>
   </r:relay>
</resData>
…

2. Use object extension

Command looks like:

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
 <command>
   <create>
     <keyrelay:create>
       <keyrelay:name>example.org<http://example.org></keyrelay:name>
       <keyrelay:keyData>
          <secDNS:flags>256</secDNS:flags>
          <secDNS:protocol>3</secDNS:protocol>
          <secDNS:alg>8</secDNS:alg>
          <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
       </keyrelay:keyData>
       <keyrelay:authInfo>
          <domain:pw>JnSdBAZSxxzJ</domain:pw>
       </keyrelay:authInfo>
       <keyrelay:expiry>
          <keyrelay:relative>P1M13D</keyrelay:relative>
       </keyrelay:expiry>
     </keyrelay:create>
   </create>
   <clTRID>123456</clTRID>
 </command>
</epp>

Poll message looks like:

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
  <response>
    <result code="1301">
       <msg>Command completed successfully; ack to dequeue</msg>
    </result>
    <msgQ count="5" id="12345">
       <qDate>1999-04-04T22:01:00.0Z</qDate>
       <msg>Key Relay action completed successfully.</msg>
    </msgQ>
    <resData>
      <keyrelay:infData>
        <keyrelay:name paResult="true">example.org<http://example.org>
        </keyrelay:name>
        <keyrelay:paDate>1999-04-04T22:01:00.0Z
        </keyrelay:paDate>
        <keyrelay:keyData>
          <secDNS:flags>256</secDNS:flags>
          <secDNS:protocol>3</secDNS:protocol>
          <secDNS:alg>8</secDNS:alg>
          <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
        </keyrelay:keyData>
        <keyrelay:authInfo>
          <domain:pw>JnSdBAZSxxzJ</domain:pw>
        </keyrelay:authInfo>
        <keyrelay:expiry>
          <keyrelay:relative>P24D</keyrelay:relative>
        </keyrelay:expiry>
        <keyrelay:reID>ClientX</keyrelay:reID>
        <keyrelay:acID>ClientY</keyrelay:acID>
      </keyrelay:infData>
    </resData>
    <trID>
       <clTRID>BCD-23456</clTRID>
       <svTRID>65432-WXY</svTRID>
    </trID>
  </response>
</epp>



—


JG


[cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com]

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Nov 12, 2014, at 11:06 AM, Rik Ribbers <rik.ribbers@sidn.nl<mailto:rik.ribbers@sidn.nl>> wrote:

James,

Thanks for the feedback. I'm fully aware of your opinion, but I'm hoping other people will step up and state their opinion on the matter.

|Can you describe to the list your issue with creating an object mapping for key relay as opposed to creating a
|combination of a protocol extension for the enqueue and an object extension for the dequeue?

Looking at the object mappings there are, we would have to provide mapping for an existing command, the most obvious ones would be:

<create> --> The keyData is not created as a result of the protocol command <create>. The key is created by the DNS operator and relayed to losing DNS operator (using the Registrar/Registry channel).

A Key Relay poll message is created.  The keyData is contained within the Key Relay poll message.  The purpose of the Key Relay object is to be enqueued into the poll queue of the losing Registrar to be consumed via a dequeue.  I don’t see an issue with creating a poll message object via a create.

<transfer> --> Transfer is not used as a transfer is all about changing ownership of data managed by the Registry.

I don’t believe transfer is applicable if a new Key Relay object extension is created, since the first step is to create the Key Relay message.  There is no need for a transfer.

<update>   --> An <update> should in our opinion be reserved for the registrar of record (for an object managed by the Registry).


Yes, I don’t see the update in play if an object extension is defined.  The extension of <update> could be used if a command response extension of domain is desired, but I don’t believe the command response extension is the right way to go.

Other commands are for obvious reasons not usable, so these are the reasons behind the choice.

|One additional question is wether two separate extensions (protocol and object) requires two separate drafts?

That's a valid question on which I don't know the answer but if needed we will split them into two drafts. Actually this would require a re-charter of the WG. Let's first wait on the feedback on the first part and then see if splitting up is required.

Rik

From: Gould, James [mailto:JGould@verisign.com]
Sent: woensdag 12 november 2014 10:24
To: Rik Ribbers
Cc: eppext@ietf.org<mailto:eppext@ietf.org>
Subject: Re: [eppext] Moving forward with the keyrelay draft

Rik,

I still believe that this can be easily accomplished by creating a single object extension called Key Relay that supports create to enqueue the poll message and the info response as the content of the dequeue of the poll message.  I understand the concern around creating an object extension for a transient object, but I don’t believe the EPP RFC’s limit the type of objects that can be provisioned.  An object can be a standard object stored in the database for subsequent update (e.g. domain, host, contact), an object can be a message object put into a queue for consumption by an authorized client (e.g. key relay), or an object can be a read-only object created by the server for various purposes like (name suggestion, registry meta-data, etc.).  Can you describe to the list your issue with creating an object mapping for key relay as opposed to creating a combination of a protocol extension for the enqueue and an object extension for the dequeue?  Creating two separate namespaces is a step in the right direction if two extensions are needed, but I believe that the use of a protocol extension for the enqueue is overly complex and can be better handled by using an object extension.  One additional question is wether two separate extensions (protocol and object) requires two separate drafts?

We can discuss this more in person tomorrow and report the results of the discussion back to the list.

Thanks,

—


JG

<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://81/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

On Nov 12, 2014, at 9:55 AM, Rik Ribbers <rik.ribbers@sidn.nl<mailto:rik.ribbers@sidn.nl>> wrote:


I've been in contact with the other authors after the discussion in the WG last Monday and there are two thing I promised to bring back to the list.

1) The authors support the standards track. Depending of the outcome of the discussion on the mailing list we will publish a new version of the document.

That was the easy part. The next part will hopefully spark some discussion on the list.

2) Major issue for moving forward with the draft is how we:
  A) Resolve the issue James Gould brought up on the namespaces  in the EPP greeting.
  B) Reach consensus on which extensions to be used.

As stated in the WG session we think none of the existing commands or the existing object mappings reflect what we want to accomplish. For us it is more then slightly modifying the protocol in our favor (as described in RFC3735).

What we want to do with the XML is in short the following
- Create a separate new namespace "urn:ietf:params:xml:ns:relay-1.0" for sending the command to the registry.
- Use the "urn:ietf:params:xml:ns:keyrelay-1.0" namespace for defining the data to be relayed.
- To avoid confusion between namespaces in the xml, rename the command from <keyrelay> to <relay>. This was originally suggested by Jay Daley on the mailing list. Side effect is that the relay command becomes more generic and can be reused for relaying data if more business cases emerge in the future.

The resulting  XML will look like this (I stripped the fluffy stuff to focus on the structure)

The EPP command:

<epp><extension>
   <r:relay xmlns:r="urn:ietf:params:xml:ns:relay-1.0">
   <k:keyData  xmlns:k="urn:ietf:params:xml:ns:keyrelay-1.0">
     ...
     {key data}
    ...
   </k:keyData>
   </r:relay>
</extension></epp>

The EPP poll response:

...
<resData>
   <r:relay xmlns:r="urn:ietf:params:xml:ns:relay-1.0">
   <k:keyData  xmlns:k="urn:ietf:params:xml:ns:keyrelay-1.0">
     ...
     {key data}
     ...
   </k:keyData>
   </r:relay>
</resData>
...

And the greeting will become like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <greeting>
    ...
    <svcMenu>
      ...
      <objURI>urn:ietf:params:xml:ns:keyrelay-1.0</objURI>
      <svcExtension>
        ...
        <extURI>urn:ietf:params:xml:ns:relay-1.0</extURI>
      </svcExtension>
    </svcMenu>
    ...
  </greeting>
</epp>

Please provide feedback on the list or come up to me if you are in Honolulu. I will be (t)here until Friday.

Rik
_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext